Skip to content

amir037/Vulnerability-Management-Program

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

78 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Vulnerability Management Program Implementation

In this project, we simulate the implementation of a comprehensive vulnerability management program, from inception to completion.

Inception State: the organization has no existing policy or vulnerability management practices in place.

Completion State: a formal policy is enacted, stakeholder buy-in is secured, and a full cycle of organization-wide vulnerability remediation is successfully completed.


image

Technology Utilized

  • Tenable (enterprise vulnerability management platform)
  • Azure Virtual Machines (Nessus scan engine + scan targets)
  • PowerShell & BASH (remediation scripts)

Table of Contents


Vulnerability Management Policy Draft Creation

This phase focuses on drafting a Vulnerability Management Policy as a starting point for stakeholder engagement. The initial draft outlines scope, responsibilities, and remediation timelines, and may be adjusted based on feedback from relevant departments to ensure practical implementation before final approval by upper management.
Draft Policy


Step 2) Mock Meeting: Policy Buy-In (Stakeholders)

In this phase, a meeting with the server team introduces the draft Vulnerability Management Policy and assesses their capability to meet remediation timelines. Feedback leads to adjustments, like extending the critical remediation window from 48 hours to one week, ensuring collaborative implementation.

Amirreza: Morning, Jimmy! How’s everything going? I know these past few weeks have been a grind for everyone.

Jimmy: Morning, Amirreza! Yeah, it’s been a bit crazy, but we’re managing. Appreciate you checking in. I went through the policy draft, and overall, it looks solid. The only concern is that with our current team size, hitting the 48-hour remediation window for critical vulnerabilities is going to be really tough.

Amirreza: Yeah, I hear you. That timeline is definitely ambitious, especially right out of the gate. What if we extend the critical vulnerability window to a week for now? We can still keep the 48-hour deadline specifically for high-risk zero-day threats.

Jimmy: That actually makes a lot of sense. We’d really appreciate that flexibility. Also, would it be possible to ease into the process for the first few months? Just so we can adapt without disrupting everything at once.

Amirreza: Absolutely. Once the policy is officially rolled out, we’re planning to give everyone about six months to get used to the new process before enforcing strict timelines. That way, teams can ramp up gradually. Sound good?

Jimmy: That sounds great! Thanks, Amirreza. It really helps to be part of the discussion instead of just getting handed down a decision.

Amirreza: Of course! This only works if everyone’s on board. I appreciate you and your team working with us on this.

Jimmy: No problem! And thanks for keeping this short—I love efficient meetings.

Amirreza: Same here! Alright, catch you later.

Jimmy: See you!


Step 3) Policy Finalization and Senior Leadership Sign-Off

After gathering feedback from the server team, the policy is revised, addressing aggressive remediation timelines. With final approval from upper management, the policy now guides the program, ensuring compliance and reference for pushback resolution.
Finalized Policy

image

Step 4) Mock Meeting: Initial Scan Permission (Server Team)

The team collaborates with the server team to initiate scheduled credential scans. A compromise is reached to scan a single server first, monitoring resource impact, and using just-in-time Active Directory credentials for secure, controlled access.

Amirreza: Morning, Jimmy!

Jimmy: Morning! I heard you’re getting ready to run some scans.

Amirreza: Yep! Now that our vulnerability management policy is in place, I want to kick off some scheduled credentialed scans in your environment.

Jimmy: Sounds good. What’s involved, and how can we help?

Amirreza: We’re planning to run weekly scans on the server infrastructure. Based on our estimates, scanning all 2,200 assets will take around 4 to 6 hours. We’ll need administrative credentials so the scan engine can log in remotely and provide a more thorough assessment.

Jimmy: Whoa, hold on. What exactly does the scanning process involve? I’m a little concerned about resource usage. Also, you’re asking for admin credentials to all 2,200 machines—that seems risky.

Amirreza: Totally valid concerns. The scan engine sends controlled traffic to the servers to check for vulnerabilities. That includes inspecting registry settings, identifying outdated software, and detecting insecure protocols or cipher suites. Credentials are necessary to get an accurate assessment without causing false positives.

Jimmy: Got it. As long as this won’t take down any servers, I think we should be okay.

Amirreza: Absolutely! To be cautious, let’s start by scanning a single server and monitoring resource usage before scaling up.

Jimmy: That’s a smart approach. Also, about the credentials, can we set up something in Active Directory? Maybe create a dedicated account that stays disabled until a scan is needed, and then we enable it temporarily? Kind of like a just-in-time access model?

Amirreza: That’s a great idea. That way, the credentials are only active when necessary. Could you have Susan set up automation for provisioning and deprovisioning the account?

Jimmy: Sounds good! I’ll check with Susan to get that started.

Amirreza: Awesome. Let me know when it’s set up, and we’ll coordinate the first scan.

Jimmy: Will do. Talk soon!

Amirreza: See you later!


Step 5) Initial Scan of Server Team Assets

In this phase, an insecure Windows Server is provisioned to simulate the server team's environment. After creating vulnerabilities, an authenticated scan is performed, and the results are exported for future remediation steps.

image

Scan 1 - Initial Scan


Step 6) Vulnerability Assessment and Prioritization

We assessed vulnerabilities and established a remediation prioritization strategy based on ease of remediation and impact. The following priorities were set:

  1. Third Party Software Removal (Wireshark)
  2. Windows OS Secure Configuration (Protocols & Ciphers)
  3. Windows OS Secure Configuration (Guest Account Group Membership)
  4. Windows OS Updates
  5. Enforce SMB Signing
  6. CVE-2013-3900 Mitigation
  7. Upgrade 7-Zip version

Step 7) Distributing Remediations to Remediation Teams

The server team received remediation scripts and scan reports to address key vulnerabilities. This streamlined their efforts and prepared them for a follow-up review.

image

Remediation Email


Step 8) Mock Meeting: Post-Initial Discovery Scan (Server Team)

The server team reviewed vulnerability scan results, identifying outdated software, insecure accounts, and deprecated protocols. The remediation packages were prepared for submission to the Change Control Board (CAB).

Amirreza: Morning! How are you doing?

Jimmy: Not bad for a Monday. And yourself?

Amirreza: Still alive, so I can't complain. Before we dive into the vulnerabilities, how did the scan go on your end? Any outages or overutilization?

Jimmy: The scan went well. We were monitoring it, and aside from all the open connections, we wouldn't have even noticed a scan was running.

Amirreza: That’s good news—I expected as much. We’ll continue monitoring, but I don’t anticipate any resource utilization issues. Do you mind if I go over the vulnerability findings?

Jimmy: Absolutely.

Amirreza: Great. I’m going to share my screen. So, the majority of these vulnerabilities stem from Wireshark being installed—most of these are simply due to it being outdated.

One interesting finding: the local guest account on the servers belongs to the local administrators group. I’m not sure why that is, but it’s something we should address.

Additionally, some vulnerabilities might be resolved through Windows updates, like the Microsoft Edge Chromium issue. The self-signed certificate warning isn’t a concern, as it’s just the computer’s self-signed certificate.

However, we should address the medium-strength cipher suites and the use of TLS 1.1 and 1.0, as both are deprecated protocols. So, in summary, our key remediation areas are:

  1. Removing outdated Wireshark installations
  2. Addressing deprecated cipher suites and protocols
  3. Removing the local guest account from the administrators group

Jimmy: Interesting. The good news is that most of our servers likely have the same vulnerabilities, which should make remediation easier.

Amirreza: Exactly—it’s a uniform loadout. Do you foresee any issues with remediating the cipher suites or insecure protocols?

Jimmy: I highly doubt it. We’ll run it through the next Change Control Board. Uninstalling Wireshark and fixing the guest account shouldn’t be an issue either—those shouldn’t be on the servers in the first place. I’ll check with our sysadmins about that.

Amirreza: Sounds good. I’ll start building out remediation packages to streamline the process.

Jimmy: That’d be great.

Amirreza: By the way, do you already have something in place to handle the Windows update-related vulnerabilities?

Jimmy: Yes, Windows updates are managed automatically, and patching should be completed by next week.

Amirreza: Excellent. I’ll start researching the best remediation approaches and update you before the next Change Control Board meeting.

Jimmy: Sounds good. Talk to you soon.

Amirreza: Talk to you soon!


Step 9) Mock CAB Meeting: Implementing Remediations

The Change Control Board (CAB) reviewed and approved the plan to remove insecure protocols and cipher suites. The plan included a rollback script and a tiered deployment approach.

Vulnerability Remediations – CAP Meeting

Facilitator: Next on the list are a couple of vulnerability remediations for the server team. The two main tasks are:

  1. Removal of insecure protocols
  2. Removal of insecure cipher suites

It looks like Amirreza from the Risk department is working with Jimmy from Infrastructure on this. Jimmy, do you want to walk us through the technical aspects of the change being implemented?

Jimmy: Normally, I would, but would you mind handing this one over to Amirreza? He actually developed the solution for us, and we’re still getting familiar with the process.

Amirreza: Sure, I can explain.

Essentially, the presence of insecure cipher suites and protocols means that the system is capable of negotiating outdated and deprecated encryption methods. If a server only supports these insecure protocols, the system might default to using them, which poses a security risk.

These settings are controlled via the Windows registry, and the fix is relatively straightforward. We developed a PowerShell script that disables all insecure protocols and cipher suites while enabling only those that meet current security standards.

Facilitator: That sounds good, but what if something goes wrong? Do we have a rollback plan in place?

Amirreza: Yes, absolutely.

First, we’re implementing a tiered deployment approach, which includes:

  • A pilot group with a small subset of systems
  • Pre-pilot and pre-production phases
  • Full deployment to production once testing is complete

Additionally, we’ve developed an automated rollback script for each remediation. If any unforeseen issues arise, the script will restore the original protocol and cipher settings.

Facilitator: That’s reassuring. Since these are just registry updates, I don’t foresee any major issues.

Amirreza: Exactly.

Facilitator: Any further questions?

Facilitator: Great! That wraps up this week’s CAP meeting. See you all next week.

Team: See you later!


Step 10 ) Remediation Effort

Remediation Round 1: Outdated Wireshark Removal

The server team used a PowerShell script to remove outdated Wireshark. A follow-up scan confirmed successful remediation.
Wireshark Removal Script

image

Scan 2 - Third Party Software Removal

Remediation Round 2: Insecure Protocols & Ciphers

The server team used PowerShell scripts to remediate insecure protocols and cipher suites. A follow-up scan verified successful remediation, and the results were saved for reference.
PowerShell: Insecure Protocols Remediation

PowerShell: Insecure Ciphers Remediation

image

Scan 3 - Ciphersuites and Protocols

Remediation Round 3: Guest Account Group Membership

The server team removed the guest account from the administrator group. A new scan confirmed remediation, and the results were exported for comparison.
PowerShell: Guest Account Group Membership Remediation

image

Scan 4 - Guest Account Group Removal

Remediation Round 4: Windows OS Updates

Windows updates were re-enabled and applied until the system was fully up to date. A final scan verified the changes

image

Scan 5 - Post Windows Updates

Remediation Round 5: Force SMB Signing on Server

The server team forced SMB Signing on the server. A new scan confirmed remediation, and the results were exported for comparison.
PowerShell: SMB Signing Remediation

image

Scan 6 - Post SMB Signing Enforcement

Remediation Round 6: CVE-2013-3900 Mitigation

The server team used PowerShell scripts to add and enable the registry value EnableCertPaddingCheck. A follow-up scan verified successful remediation, and the results were saved for reference.
PowerShell: EnableCertPaddingCheck

image

Scan 7 - Post Mitigation of CVE-2013-3900

Remediation Round 7: 7-ZIP Version Upgrade

The server team used PowerShell scripts to upgrade 7-ZIP to the latest version. A follow-up scan verified successful remediation, and the results were saved for reference.
PowerShell: Upgrade 7-ZIP

image

Scan 8 - Post 7-ZIP Upgrade


First Cycle Remediation Effort Summary

The remediation process reduced total vulnerabilities by 86.2%, from 29 to 4. Critical vulnerabilities were resolved by the second scan (100%), and high vulnerabilities were resolved by the seventh scan (100%). Mediums were reduced by 82.35%. In an actual production environment, asset criticality would further guide future remediation efforts.

image

Remediation Data


On-going Vulnerability Management (Maintenance Mode)

After completing the initial remediation cycle, the vulnerability management program transitions into Maintenance Mode. This phase ensures that vulnerabilities continue to be managed proactively, keeping systems secure over time. Regular scans, continuous monitoring, and timely remediation are crucial components of this phase. (See Finalized Policy for scanning and remediation cadence requirements.)

Key activities in Maintenance Mode include:

  • Scheduled Vulnerability Scans: Perform regular scans (e.g., weekly or monthly) to detect new vulnerabilities as systems evolve.
  • Patch Management: Continuously apply security patches and updates, ensuring no critical vulnerabilities remain unpatched.
  • Remediation Follow-ups: Address newly identified vulnerabilities promptly, prioritizing based on risk and impact.
  • Policy Review and Updates: Periodically review the Vulnerability Management Policy to ensure it aligns with the latest security best practices and organizational needs.
  • Audit and Compliance: Conduct internal audits to ensure compliance with the vulnerability management policy and external regulations.
  • Ongoing Communication with Stakeholders: Maintain open communication with teams responsible for remediation, ensuring efficient coordination.

By maintaining an active vulnerability management process, organizations can stay ahead of emerging threats and ensure long-term security resilience.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors